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^ integrated design environment enables the formation of business applications for usage on a commerce server 
ZZJ^^T^ r"^"'^ f components including but not limited to business objects, business steps, 

behavior and ^^'aySlters, and busmess rules ananged as a workflow. The design enviromnent provides graphical interfaces for 
^ement and moAfi«t.on of the com^^ The project based design environment includes project files with components 
su«ed as files, with the files often bemg fimcdonally intenJependent. The design environment provides for integrated airanrement 
of the components via the convenience ofagiaphical interface, and provides for validalionofthei^ 

i^ed. A busme^apph^ation can thereby be viewed and/or developed with automatic cmsschecking and generated documentation 
of ttie vanous intenlependent component parts. This arrangement is facilitated, in part, through an interim metadata representation 
that encodes basic mfoimaton for use by a semantically richer internal object model, and the overall commerce server 
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INTEGRATED DESIGN ENVIRONMENT FOR A 
COMMERCE SERVER SYSTEM 



RELATION TO PRIOR APPLICATIONS 
This application is related to U.S. Provisional patent application having 
serial number 60/164,021, entitled "Method and Apparatus to Provide Custom 
Configurable Business Applications From a Standardized Set of Components," 
filed August 23, 1999, by one of the same inventors, and which is hereby 
incorporated by reference in its entirety. This application is also related to utility 
patent appKcation having serial number 09/440, entitled "Method for Providing 
Custom Configurable Business Applications from a Standardized Set of 
Components," filed November 15, 1999, by one of the same inventors, and which 
is hereby iiKorporated by reference in its entirety. This application is also related 
to utility patent plication having serial number 09/439,764, entiUed "Apparatus 
to Provide Custom Configurable Business Applications firom a Standardized Set of 
Conqwnents," filed November 15, 1999. by one of the same inventors, and which 
is hereby incorporated by reference in its entirety. 

FIELD OF THE INVENTION 
The present invention relates generally to an integrated design environment 
that provides various graphical tools and interfaces to f acUitate the efficient 
formation and verification of business applications for running on a commerce 
server system. 

BACKGROUND OF THE INVENTION 
The prior referenced applications provide for methods and apparatuses for 
creating custom configurable business or channel applications firom a standardized 
set of components. More specifically, the referenced invention aUows each 
business to select firom a set of applications, customize that set of applications, 
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and/or develop new customized applications from a set of development 
components. The prior applications provide for a server based method wherein 
best-of-breed services and/or appUcations are integrated in a seamless fashion and 
offered to enterprise businesses which develop customized business service 
applications through using the system. The server device is previously (and 
hereafter) referred to as the Asera Commerce Server (ACS). 

The ACS includes a Commerce Server that provides a core set of 
technology (or appUcation) services. A unique architectare and framework are 
provided by the Commerce Server which faciUtates development and use of 
customized applications. All interactions with external systems or users are 
managed as business objects. The service appHcation code is maintained separate 
from the data, Aereby enabling the system to quickly include or change new 
business processes or technology components without having to write substantial 
amounts of new code. The business result is more rapid customer deployments 
and/or modifications that are customized to the level of including (if desired) the 
proprietary or conq)etitive business practices of a contracting conpany. 

The ACS can be viewed as a form of ASP (AppUcation Service Provider). 
An ASP is generally an outsourcing business model. The ASP business model 
requires an open and extendable architecture that allows a system to implement a 
customer specific business solution in a short period of time. The ACS takes best- 
of-breed appUcations and incorporates them into one integrated solution to provide 
the ASPs. The architecture is scalable and extensible. A customized business (or 
channel) appUcation solution is built for each enterprise company. The solution 
uses a "modular" or step-wise or "plug and play" approach towards building new 
^Ucations. An enterprise company can then quickly acquire a turn-key e- 
commax» solution to automate their channel relationships. The system presents 
Utfle (or no) risk for the enterprise company because a solution is built by the 
present system. The costs of undertaking such a development exist as a fixed 
development cost of the system Any resulting customized solutions are 
in5)lemented in considerably less time than previous systems. The enterprise 



company might pay for the application services on a cost per transaction, or a 
fixed fee basis. 



The ACS is used to capture the particularized (or specific) business 
processes for a given customer, and these business processes are converted into a 
set of customized applications. The ACS uses business steps and rules to 
construct the application. The objects are data representations. The steps are 
business operations with a defined set of mput and output ports, with each port 
also having a defined set of parameters. The business rules are used to capture 
customer specific business practices. A unique tool that en5)loys a graphical user 
interface (GUI), aUows a developer to arrange various steps (or composite steps) 
mto business processes, or workflows. The tool provides Kbrary catalogs of steps 
to be appHed to the various objects. The connections between steps are also 
verified as correct A graphical display of the business process is shown, and rules 
can thereafter be ^pHed to provide fiorther customization by conditionaUy tagging 
certain points. Hence, to create a business process (or application) for any given 
business, tools are provided which allow modules (or steps) to be plugged or 
dropped into ihe potential process. The steps can be moved, or the connections 
modified. An initial person-to-person (or other type of) interview with the 
business (or customer) can be used to produce the fi-amework for arranging the 
steps according to the needs of ttiat particular business (i.e. customized routines). 
The modular aspect of the present system aUows this to be done - and 
modifications made - in a relatively quick fashion. For instance, if a process has 
been created, but the customer wants it to behave in two different manners, then 
certain rales can be ^lied to provide the desired results, depending on 
conditional triggers that can be associated with the underlying business objects. 

In general, Litemet transactions can be divided into two categories: 1) 
business-to-business transactions, and 2) business-to-consumer transactions. Most 
solutions to automate transactions have dealt with business-to-consumer 
interactions. As such, these interactions are much more straightforward than 
business-to-busmess transactions. In a business-to-consumer transaction, the 
merchant supplies a "storefix>nt" or web site that offers products to any number of 



diversified consumers who might wish to view this web site. The consumer then 
purchases a product via a selection and payment method, and the product is 
thereafter shipped to the consumer. On the other hand, when one business deals 
with another business, there is a much greater amount of business processes and 
customization in the transactions that occur. 

The prior referenced applications describe a graphical user interface (GUI) 
tool that can be used to selectively arrange the business objects or steps into a 
working application. The implementation describes various screens for 
manipulating the business steps and their associated input ports and output ports. 
Business rules can also be applied to guide the flow of the assembled steps. The 
resulting appUcation corresponds to apphcation code (XML or otiierwise) tiiat is 
used by the commerce system to achieve the particular (customized) business 
processes desired by the user. StiU ftirther detaUs of the integrated design 
environment (i.e.. appUcation builder) tool in^jlementation, and various enhanced 
features, are provided in tiie present invention in order to furflier describe and 
clarify the tooL 

SUMMARY OF THE INVENTION 
The present invention provides a data source layer framework for conveying 
data between business appUcations and external data sources. The underlying 
commerce system is first summarized, and thereafter the data source layer 
framework of the present invention is sunmiarized. 

To achieve the foregoing, and in accordance witii the purpose of the present 
invention, the system described includes, for example purposes, a server device 
referred to as the Asera Conomerce Sender (ACS). The ACS provides for tiie 
development and implementation of customized, automated, web-based business 
service appKcations. The ACS provides for a server based method wherein best- 
of-breed services and/or plications are mtegrated in a seamless fashion and 
offered to enterprise businesses tiiat develop customized business service 
plications through using the system. 



The ACS includes a Commerce Server that provides a core set of technology 
(or application) services. A unique architecture and framework are provided by 
the Commerce Server that facilitates the methods described herein. All 
interactions with external systems or users are managed as business objects. The 
service application code is maintained separate from the data, thereby enabling the 
system to quicMy include or change new business processes or technology 
components without having to write substantial amounts of new code. The 
business result is more rapid customer deployments and/or modifications that are 
customized to the level of including (if desired) the proprietary or competitive 
business practices of a contracting company. 

Hie ACS thus can be viewed as an ASP, or Application Service Pi-ovider. 
An ASP is generally an outsourcing business model. The ASP business model 
requires an open and extendable architecture that allows a system to implement a 
customer specific business solution in a short period of time. The ACS takes best- 
of-breed ^Kcations and incorporates them into one integrated solution to provide 
the ASPs. The architectiire is scalable and extensible. A customized business (or 
channel) appUcation solution is built for each enterprise conpany. The solution 
uses a "modular" or step-wise or "plug and play" approach towards building new 
applications. An entesrprise company can tiien quickly acquire a turnkey e- 
commerce solution to automate their channel relationships. The present system 
presents little (or no) risk for tfie enterprise company because a solution is built by 
the present system. The costs of undertaking such a development exist as a fixed 
development cost of the present system. Any resulting customized solutions are 
implemented m considerably less time than previous systems. The enterprise 
con5>any might pay for the ^plication services on a cost per transaction, or a 
fix^ fee basis. 

The ACS is used, to capture the particularized (or specific) business 
processes for a given customer, and these business processes are converted into a 
set of customized applications. The ACS uses business steps, and rules to 
construct flie plication. The objects are data representations. The steps are 
business operations wifli a defined set of input and output ports, with each port 



also having a defined set of parameters. The business rules are used to capture 
customer specific business practices. A unique tool that employs a graphical user 
interface (GUI), allows a developer to arrange various steps (or composite steps) 
into business processes, or workflows. The tool provides Kbrary catalogs of steps 
to be applied to the various objects. The connections between steps are also 
verified as correct. A graphical display of the business process is shown, and rules 
can thereafter be applied to provide further customization by conditionally tagging 
certain points. Hence, to create a business process (or application) for any given 
business, tools are provided which aUow modules (or steps) to be plugged or 
dropped into the potential process. The steps can be moved, or the connections 
modified. An initial person-to-person (or other type of) interview with tiie 
business (or customer) can be used to produce the firamework for arranging the 
steps according to the needs of that particular business (i.e. customized routines). 
Tbe modular aspect of the present system allows this to be done ~ and 
modifications made - in a relatively quick fashion. For instance, if a process has 
been created, but the customer wants it to behave in two different manners, then 
certain rales can be applied to provide the desired results, depending on 
conditional triggers that can be associated with the underlying business objects. 

The underlying commerce server provides certain functional con5)onents. 
Tliereafter, various vertical applications are built (and/or customized) for the 
particular enterprise business. A suite of best-of-breed components and 
underlying applications are chosen to con^rise, or run on top of, tiie commerce 
server. These components can be selected as the best technologies to provide 
certain desired efficiencies, cost reductions, and the like. The best-of-breed 
con^Kments are thereafter incorporated (or interfaced) with tiie business 
appKcations through APIs. A catalog of APIs can be provided for developers of 
^hcatioQS. Jf any underlying best-of-breed components change, tiien the 
commerce server configuration can be changed without interfering with any user 
interfaces. 

The integrated design environment (IDE) of tiie present invention adds tiie 
gr^hical ability to take an XML (or otiier) representation of an application and 



present it in a structured, hierarchical way for formation of an application to run 
on the commerce server system. The particular IDE discussed in the present 
invention is also referred to the "application builder." The analysis and formation 
of XML files via line editors has proven to be too cumbersome, error-prone, and 
time consuming. The files representing the various business objects (or the like) 
can be formed and cross-checked for accuracy in their interdependences. This is 
facilitated by having the commerce server interact with a metadata representation 
of each ^plication as formed from the integrated design environment. The 
metadata layer is capable of reading an XML file and creating a "bare-bones" in- 
memory object representation of a particular component. The metadata format 
captures only the essential data that represents a particular instance of an 
plication component. The tool internal object model, however, is used to 
convert each basic metadata object into a semanticaUy richer representation. The 
richer representation thereby allows additional logic and structure that permits the 
integrated design environment to present semanticaUy rich user interfaces which 
support a variety of complex features. 

Ihe integrated design environment uses project-based development A 
project-based approach groups a set of conqwnents into logical groups or modules, 
wherein most conqwnents typically depend on other components. 

The present application also performs semantically rich component 
validation. More than parsing and evaluating the syntax of an XML file, the 
present system vaUdates the content of the XML files. The tool is capable of 
perfonmng deep semantic conponent validation, botii of individual components, 
and moTB significantiy, across components. 

An "Aseradoc" feature is also available which provides for conqjonent 
documentation. Developers are able to document components within the tool, 
even without entered comments being direcfly associated witti the code. Any 
comments fliat might have been entered, however, are integrally incorporated into 
the final generated documentation. The user-supplied documentation is persisted 



in the component's XML file, which is more likely to be maintained (and 
persisted) than externally supplied comments. 

Accordingly, one aspect of the present invention includes an integrated 
design environment to facilitate formation of a business application having 
business objects which are maintained as independent files, the resulting business 
application to be used on a commerce server system, the integrated design 
environment conqjrising: an area for displaying a project tree hierarchy and 
selectively choosing a project file for graphical display; a detail viewing area for 
selectively displaying a structured view of the project file, or displaying a 
workflow view of the project file; a properties configuration area for displaying 
and selecting properties associated with a selected item object in liie detail viewing 
area; a comments area for displaying and facilitating entry of comments associated 
with a selected item object in the detail viewing area; and a message area for 
displaying a variety of warning, error, and/or status messages associated with 
validation of the project file in relation to the various mterdependencies of the 
object files coniprising the business application. 

Another aspect of tfie present invention includes a formation and validation 
tool for building a business application having business objects which are 
maintained as independent files, the resulting business appHcation to be used on a 
comnoerce server system, the tool comprising: a file represenlation; a metadata 
layer for reading the file representation and creating a basic object representation 
of a particular con5)onent; an object model representation layer that uses the 
metadata layer to c^ture information necessary to perform cross-component 
project validation; an plication builder device that uses the object model 
representation layer to form and display applications; and a commerce server 
device that uses the metadata layer to retrieve the information needed to validate 
and/or execute the business objects. 

Another aspect of the present invention includes an integrated design 
aivironmeot for the formation of applications to be run on a commerce server 
system, the integrated design environment comprising: a plurality of objects 



represented as ffles for forming the appUcations, whereby each of the files can be 
interdependent upon other files within the system; a graphical display for 
arrangement of the pIuraKty of objects; and a vaHdation routine for verifying the 
interdependendes as being functionally correct for the given object arrangement. 

These and other aspects and advantages of the present invention will 
become apparent upon reading the following detaUed descriptions and studying 
the various figures of the drawings. 

BRIEF DESCRIFnON OF TEffi DRAWINGS 
The invention, together with further advantages thereof, may best be 
understood by reference to the followmg description taken in conjunction with the 
accompanying drawings in which: 

Figure 1 shows a block diagram, according to one aspect of the present 
invention, which shows interdependencies between files in the system. 

Hgure 2 shows a block diagram, accorduag to one aspect of the present 
invention, which shows the tool internal object model, and associated metadata 
layer for formation (and crosschecking) of an application. 

Figure 3 shows a block diagram, according to one aspect of the present 
invention, which shows a high level architecture of the Tool Internal Object 
Model. 

Figure 4 shows a block diagram, according to one aspect of the present 
invention, of flie elem^ts conprising a document tree node. 

Kgure 5 shows a block diagram, according to one aspect of the present 
invention, wherein die mterfaces between operands are facilitated through object 
choosers and editor invokers. 

Rgute 6 shows a block diagram with details of the mf ormation stored in the 
metadata layer. 
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Figures 7-19 show various screen displays of the integrated design 
environment, which serve to explain certain features integrated throughout. 

DETAILED DESCRIFnON OF THE INVENTION . 
The present invention offers a low risk alternative for companies that wish to 
quickly deploy an automated business application to their customers. In doing so, 
the con^any will interact with Asera personnel to capture various business 
processes to be inplemented for the company. Thereafter, the conq)any will have 
these business applications running on the Asera servers for use by both, the 
customers and suppliers. Accordingly, an integrated design environment is needed 
for efficiraitly developing business applications from the component parts as 
defined by tiie system. TTie integrated design environment should provide (at 
least) certain graphical interface tools that allow for arrangement of the workflow 
steps, and verification of the step arrangements thereafter. 

To create ACS business applications, or the like, application engineers first 
create several types of components that are encoded and persisted as XML 
(ExtensiTjle Markup Language) files, or the like. Hiese con^nents include, but 
are not limited to: (1) Business Objects; (2) Business Object Configurations; (3) 
Business Steps, including (a) simple steps (including normal, virtual, 
in^lementation), (b) interactive steps (normal, virtual, implementation), (c) 
con^KJsite steps (normal, virtual, implementation); (d) bridge steps, (e) transition 
steps; (4) Behavior HIters; (5) Display Filters; (6) Message Resource files; (7) 
Image Resource files; (8) Enumerated types; (9) Named Candidates; (10) Named 
Criteria. In flie present embodiment (and for exan^jle purposes), the components 
migjit be persisted as XML files, or HTML files. In addition to being XML files 
(or HTML, (x other languages) files, the objects, configurations, and steps can also 
refer to each other. Hence, any given file may not be independent. 

Referring now to figure 1, a block diagram 100 is shown of the 
inter<tependencies that might exist between the representative files. Such 
interdq)endencies might include hyperlinks or other dependencies. Filel (102) is 
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shown interdependent with FileS (106). File2 (104) is shown interdependent with 
Filel and Rle3. File3 is similarly shown interdependent with Filel and File2. 
These interdependencies are meant to be representative only, and other 
combinations are meant to be included with an ever-increasing complexity of file 
structures. --^'^ 

An application engineer, professional services engineer, or the like can 
create and edit XML ffles by using a text or XML editor. However, this practice is 
tedious, error-prone, and time-consuming. In addition, certain types of artifacts, 
such as con^wsite business steps (which can be used to capture workflow logic) 
are most naturaUy described in a graphical (diagrammatic) manner. Furthermore, 
even relatively simple artifacts, such as business objects, can be relatively 
conq)lex to describe in XML, but very simple to describe using a customized 
gr^hical user interface (GUI). 

For exan^le Appendix B provides an XML representation of a business 
object definition. This particular BOD is the calculator example used tiiroughout 
this description for exan^le purposes. The line-by-line code proves to be difficult 
to read and the workflow represented by the XML code is difficult to discern firom 
the code. In contrast. Appendix C shows a view provided by the present invention 
of the same business object definition. Hie structure view chosen provides a 
Metarchical Ksting in the display window, as shown. Other views and screens can 
shmlarly show the workflow as an easy to discern graphical workflow. 

The Application Builder (referred periodically throughout ftis description as 
flie "tool") is an integrated development environment (IDE) for creating and 
manipulating ACS artifacts. The tool consists of a general extensible framework 
and a set of custom plug-in "editors" - with one for each type of artifact. The tool 
performs additional input validation when loading XML artifacts, tiiereby 
identifying errors very early in the design process. Furtiiermore, each custom 
editw, to a large extent, also prevents tiie user from creating ill-defined or invalid 
arti£acts. 
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Certain features of the tool include, but are not limited to the following: 

(1) Hie tool uses project-based development Most components will 
typically depend on other components. With a project-based approach, sets of 
conq)onents are grouped into logical groups or modules. 

(2) GUI productivity features, such as cut/copy/paste, mouse-click 
navigation, and persistent user preferences and settings. 

(3) SemanticaUyrichvahdation. While XML parsers can be used to 
validate the syntax of an XML file (i.e., whether the file is "weU-formed"), they 
cannot be used to vaHdate the content of the XML files. The tool is capable of 
perfonning deep semantic component validation - both of individual conponents, 
and more significantly, across components. Since most con^nents depend on 
other conqMMients, this cross-component validation is extremely powerM. It can 
significantly reduce development effort and time by clearly identifying a broad 
variety of errors very early in the software design cycle. 

(4) Integrated build utility. This feature enables the developer to 
automatically g«ierate various derived files, such as JSP source files, Java class 
files, generate makefile dependencies, and to automatically remove such generated 
files. FurthennoTB, the developer can apply such actions to the entire project or 
selectively - to subsets of the project, 

(5) A documentation feature ~ referred to as "Aseradoc" ~ which 
allows a developer to document components within the tool. Such documentation 
is persisted in fte con^jonent's XML file, making it more likely that the 
documentation will be kept up-to-date as the component is modified. 
Furthermore, the tool can format the user-suppUed documentation into a collection 
ofHTML files that can be viewed by a standard web browser. Agam, unlike 
independent static documents that are less likely to remain current as the software 
components ate modified, the tool can be used to easily generate the most current 
documentation with a single mouse click, thereby facilitatmg iterative software 
development 
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An example of a samplQ Aseradoc output file is shown in Appendix A. The 
file represents an HTML file that was generated for a business object definition, 
and in particular tiie calculator example of the present detailed description. An 
attribute summary is provided, along with details of each of the attributes. 
Relations might also be shown, though this example does not contain any. 

Referring now to Figure 2, a block diagram 200 is shown of a high level 
architecture representing the present system. Graphical tools such as the 
AppHcation Builder 202 and the Diff/Merge upgrade tool 204 are built on top of a 
generic Tool Intemal Object Model (TIOM) 206 as shown. In order to read or 
write an XML (or the other type) of file 212, the appUcation builder 202 uses 
functionality provided by the metadata layer 208 that it shares with the server 210 
(i.e., Asera Commerce Server or ACS). The metadata format captures only the 
essential data that represents a particular instance of an ^plication component. 
The TIOM 206, on the other hand, converts each such metadata object into a 
semanticaUy richer rqjresentation. This model provides additional logic and 
structure that allows the Application Builder 202 to present semantically rich user 
interfaces which support a variety of complex features. 

The GUI might offer any of a variety of features, including for instance 
intelligent structure views. Such views might support common user actions across 
allconqwnents. Such actions might include (but are not limited to): (a) cloning of 
a selected child; (b) moving a selected child up or down relative to its siblings; (c) 
removing all children from a parent; (d) removing a particular child from a parent; 
(e) expandmg and/or collapsing all children, a portion of the children, etc.; and (f) 
keyboard-based cutfcapy>^aste. The GUI might further provide context-sensitive 
property sheets, toolbars, and popup menus. Coinments and/or documentation 
windows (panes) ini^t fintiier be included. 

Regardmg the cutfcq)y/paste feature, unlike a text editor in which a user 
cuts/copies^yastes text, the building blocks of ACS corcponents are highly varied. 
Each component has its own rules that govern where such building blocks can 
^ipear. The tool siq>pcMte this heterogeneous target/source model. For example, a 
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step input port can be pasted only inside an "input port's" construct of a step, and 
only if that "input port's" construct does not already contain the maximum 
allowable input ports. Similarly, the tool will prevent users from cutting or 
removing certain constructs, as doing so would violate a rule associated with the 
parent container that states that the parent must contain some minimum number of 
child con5)onents. For example, a simple step must always contain exactly one 
input port and one output port. In this case, both the input and output port can be 
copied, but neither one can be removed or cut. Similarly, other input or output 
ports cannot be pasted in the input port node of a simple step. 

The GUI might further provide for a browser-style forward^ack selection 
history mechanism. Other navigation commands might include a double mouse- 
click as a means to drill down to details oY to jun^ to related components. A 
persistent session history might also be provided. For instance, recent/last 
projects, window sizes and positions, and other session information is recorded 
and automatically maintained between sessions. 

Referring now to Figure 3, a block diagram 300 is shown with fiather 
representative details of the Tool Internal Model (206) from Figure 2. This 
diagram is generally meant to serve as a single consistent representation that 
c^tures (among other things) certain information necessary to perform (a) cross- 
component project validation; (b) generate documentation, and (c) application of 
standard UI features across different types of conponents. Note that the boldface 
connector arrow 302 indicates that a transition from one element to another has 
many instances, whereas the open-faced arrow 304 indicates only one instance. 

The first element is the project 306. A project is a collection of web 
plication conqjonents. A project ffle is itself an XML file that encodes the 
names of the constituent components and other project settings. In memory, each 
project object contams a collection of references to document objects. 

The next element 308 represents a document object. A document object is 
the tool layer's variant of a metadata object Each document object contains a 



15 



reference to a corresponding DocuroentUI object 3 10, and a reference to a 
DocumentTreeNode object 312 that is the root of the Document's hierarchical 
representation. Each document is described as a hierarchy that is constructed from 
variants of the DocumentTreeNode objects. Each such variant can be customized 
to serve in a variety of situations. The key aspect of this mode of construction is 
that all DocumentTreeNode objects support a common set of functionality. 

The DocumentUI object 310 is used to define the set of graphical views that 
a particular type of component exposes to the UI. For example, a composite step 
conqKMient exposes two views in the UI: a structural view and a "workflow" view. 
A business object definition, for example, exposes three views: a structural view, 
an attributes (tabular) view, and a relations (tabular) view. 

The DocumentTreeNode 312 represents a tree structure of child nodes. Each 
node object contains an ordered collection of zero or more child nodes. These 
nodes include an extensible collection of properties, including but not limited to: 
optional name; optional comment text (both as a single text string, or multiple 
tagged conaments); optional caption text Each node has a reference to a 
NodePolicy object 314 (wherein each policy is typicaUy shared among many 
nodes). Each node fiirther includes an optional reference to a PrototypeGroup 
object 316. In addition, each subclass (variant) of DocumentTreeNode can be 
customized in many ways, including but not limited to: custom logic to expose 
properties in a "property sheet"; custom component validation logic; custom 
documentation generation logic; custom clipboard manipulation logic (that 
detmnmes what constructs can be cut/copy/pasted); custom logic to determine 
minimum/maximum number of children constraints; and custom unique key 
goieration logic. 

Ihe NodePolicy object 314 is used to describe tiie structure and behavior of 
a particular class of DocumentTreeNode objects. Specifically, a NodePolicy can 
be used to capture the following information: whether the children of the node 
need to have unique names; whether the node has a prototypical child instance, 
ami a determination of that instance. Each such prototype can be used to create 
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additional children in a "cookie-cutter" fashion; actions that should be used to 
generate a new child; the set of actions supported by the node; a determination of 
the set of validator objects that can be used to validate an instance of the node. 
Notably, each DocumentTreeNode variant can implement its own custom 
validation by extending standard behavior; A determination of the set of standard 
documentation objects that can be used to generate automatic documentation (i.e., 
an "Aseradoc") for this node. 

The PrototypeGroup 316 is an object that contains a collection of 
DocumentTreeNode, each of which is a prototypical instance of some 
DocumentTreeNode object. This collection of prototypes is used to define a Hst of 
valid types of objects. 

The DocumentTreeNode 312 of Figure 3 is further detailed in Figure 4 via a 
representative example 400, in this case a calculator application. The BOD 
(Business Object Definition) 402 is first shown having a name that uniquely 
identifies the application in the system, i.e., com.asera. . .calculator, or the like 
(wherein any of a variety of identifier strings might be included in-between the 
particular words shown). The BOD also includes the name of other BODs that are 
extended by it In general, Ais will include knowledge that the name refers to a 
BOD, Mid a chooser^voker device can be used to select the particular BODs. 
Each BOD 402 contains (at least) a collection of attributes 404, a collection of 
relations 406, and a collection of configurations 408. 

The attributes 404 might further include operations, including but not limited 
to operations and constraints/policies. Example operations might include: "add 
attribute" (to create an attribute object, i.e., 410 or 412 below); "remove children" 
(i.e., remove all attributes); "expand"; or "collapse." Example constraints/poUcies 
might include naming of the children (i.e., each of the children has a unique 
name); SOTting of the children by name; and limitations on the minimum or 
maxinHim number of children (i.e., ranging fi-om zero to infinity). 
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A number of attribute objects 410, 412, and so forth, are shown as a subset 
of the attributes 404. Each attribute object might include operations such as 
"clone" or "remove." The attribute objects further include properties such as: 
object name; domain (via select list); enumeration flag (i.e., IsEnum, Boolean); 
cardinaKty (via select Kst); requirement flag (Boolean); and/or persistence flag 
(Boolean). "Object choosers" might also be used to select valid references to other 
objects (i.e., interactive steps). 

Moreover, some properties will be used to capture knowledge related to 
object and file references. For example, an interactive step refers to both display 
filters and HTML wireframe files. A sin?)le step refers to Java source files. Steps 
in general might refer to other contained steps. In each such instance, the use of 
smart choosersyinvokers forces the user to select "valid values." Referring now to 
Figure 5, Object 1 (502) uses Object 2 (504), Java File 1 (506) and HTML File 2 
(506). The object type information is encoded to know what type of object 
chooser/editor invoker to apply in light of certain properties. 

Referring again to Figure 4, configurations 408 are shown. This consists of a 
list of one or more busmess object configuration (HOC) components. As similar 
to relations (406) above, the name of each BOC should correspond to a vaUd BOC 
conqxment Accordingly, an object chooser and editor invoker are used to select 
and validate BOC con^xments. 

Figure 6 shows farther details of the metadata component 208 from Figure 2, 
in Kght of tfie above calculator ^plication exanple. As stated above, tiie 
metadata layer is c^Ie of reading an XML file and creating a "bare-bones" in- 
memory object rejaesentation of a particular component The metadata format 
captures only the essential data that represents a particular instance of an 
application component This bare-bones representation does not facilitate the 
vahdation between the various components, as only basic information is captured. 
The metadata is shown have a list of information 602 pertaining to each BOD. In 
this instance, the information pertaining to each attribute is listed, i.e. name = 
Operandi, type = integer, cardinality = single, IsRequired flag = false, IsPersistent 
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flag = trae, and the name/list of a business object that this attribute extends. 
Similar attributes are also listed. Relations are shown, including (for example) 
name, BOD name, cardinaHfy, and IsRequired. A Kst of components (not shown) 
might sinailarly be listed. 

Figures 7-19 show certain screen displays of the example calculator 
appUcation as formed using the present system. Hie tool herein might be executed 
as a stand-alone Java appHcation. Alternatively, the tool might also run as a Java 
applet fliat is executed within a web browser. As indicated above in the high-level 
figures, the application bmlder operates on projects. A project file contains a list 
of business objects, configurations, business steps, and wire fi-ame files that are 
contained in the project Project files are readily created, added, or removed via 
normal con^uter operations. 

Figure 7 shows the main window 700 of the Application Builder, which 
consists of several areas. The project tree area 702 displays a folder hierarchy of 
project items. The detail pane 704 contains a set of tabbed panes that display 
detailed information about the selected project item. In this example, the detail 
pane presents a detailed view of a con:q)osite business step. The message pane 706 
displays a variety of warning, error, and status messages. For instance, double- 
cliddng on an error message will drive the selection in the detail view to display 
the error item. The property sheet 708 displays properties for the selected item in 
die detafl pane. The comments pane 710 displays user-entered comments 
associated with the selected item in the detail pane. The context-sensitive toolbar 
712 displays actions that can be performed to the selected item in the detail pane. 
IWs same set of actions can be accessed by right-cHcking on the item in the detail 
pane. 

The tool's GUI is similar to otiier Integrated Design Environments (IDEs). 
As such, the top left pane displays a tiree of project items. Any item can be 
displayed and edited by double-clicking on its name in the project tree conti-ol or 
right cHcJdng on its name and selecting "edit" from the popup menu. The item 
details are di^kyed in a tab control located in the top right pane. The tab control 
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contains several tabs, with the set of tabs that is displayed depending upon the type 
of item being edited. Modified files might be saved by right-clicking on an item to 
be saved (in the project tree), and selecting "save" firom the popup menu, or 
invoking "file-save" or "file-save-all" fi-om the toolbar. 

Referring now to Figure 8, each business object definition (BOD) 800 has 
the foDowing tabs: A structure view 802, which is a tree view of the attributes and 
relations of a business object; Attributes 804, wherein this tab is used to 
manipulate the attributes of a business object. Each attribute has properties such 
as name, domain (data type), cardinality, and flags (i.e., a flag to indicate if the 
attribute is used as a key, or if the attribute is required, or if the attribute is 
persisted). Relations 806, wherein this tab is used to manipulate the relations of a 
business object Each relation has properties such as name, type (Business 
Object), cardinaKty, required and persisted flags, and association which can have a 
value of "reference" (i.e., the object contains a reference to a business object of tiie 
specified type), or "containment" (i.e., the object contains an instance of the 
business object of the specified type). 

Each node in the structure view 802 can be manipulated by eitiier invoking 
an action or by modifying a property. When a tree item 808 is selected, the 
toolbar 814 is automaticafly updated to show actions that can be appHed to the 
selected item. SimOarly, the property sheet 812 automaticaUy displays properties 
associated wifli the selected iteuL Actions are invoked by cHcking one of the 
toolbar buttons 814, or by selecting the action from a context-sensitive popup 
menu 810. Prqperties are modified in the property sheet 812. 

Figure 8A further shows a screen 850 with the attributes 804 tab selected. 
This screen provides a tabular (spreadsheet) view of the attributes of the BOD. 
This spreadsheet provides an overview of the attiibutes and their key properties, 
i.e., name, domain, cardinality, and relevant flags (required and persistent). 

Figure 9 shows the business object configuration represented as a ti-ee 900 
within the GUI. The tree contains several top-level folders, i.e., (1) In-Useltems; 
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(2) Unused Items; (3) Name Groups; (4) Named Rules, wherein users can create 
one or more name rules. Rules are made up of a set of actions and conditions; (5) 
Object Triggers, wherein users can associate a number of rules with object-level 
trigger points, as is similarly done for individual attributes and relations. Such 
trigger points might include "BeforeFetch", "AfterFetch", "BeforeChange", 
"AfterChange", "AfterCreate", and "BeforeDelete"; (6) Queries; (7) Properties. 

Figure 10 further shows a screen 1000 for the manipulation of business steps. 
Business steps are edited using several types of detailed views. For instance, aU 
business steps contain the "structured view" tabs 1002 that can be used to display, 
create, delete, and modify input and output ports, and a set a variety of top-level 
properties. Conq)osite steps are thereafter defined in the "work flow" tab 1004, 
which implements a gr^hical drawing (or workflow) editor, as presently shown in 
the figure. By default, the workflow editor can be used to move step instances by 
cHcking the left mouse button on a step instance label, dragging the label, and the 
placing the step instance in the desired location (i.e., drag-and-drop operation). 
The defauh popup menu can be displayed by cHckmg the right mouse button on an 
empty space. To create a new step instance, the user can select "add step instance" 
fiiom the default popup menu. To create a new hnk, the user can select "add link" 
fiTom the defaultpopup menu, click on the source step instance, drag the item to 
the target step instance, and place it thereafter. 

Step instances and links can be edited by clicking on the instance of the label 
or link selection rectangle, and selectmg the desired editiag command fi-om the 
step instance or link popup menus. When a step instance or Imk is first created, it 
is drawn m a light (gray or otherwise) color, thereby indicating that the step 
instance has not been m^d to a step definition, or the Hnk has not been mapped 
to Ae input and output ports of its target and source step instances. When a step or 
link is correctly m^>ped, then the associated step instance label or link selection 
rectangle is drawn in another color (i.e., green). The instance label or link 
selection rectangle is drawn in yellow or red to mdicate fliat one or more of the 
pOTts of the step instances are invalid or one or more of the tiransitions represented 
by the hnk are invalid. In such a case, the user should right-click on the invaUd 
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object to bring up a context menu that will indicate which port or transition is 
invalid. Selecting the submenu associated with this port or link will allow the user 
to select a "describe error" action from the menu. This will in turn display a 
descriptive OTor message in the messages pane. 

Lmks may represent two or more transitions, in which case the link selection 
rectangle will be replaced by two stacked rectangles. The popup menu for 
multiple transition links will list all transitions between the pair of step instances. 
The editor automatically generates several step instances, i.e., "enter", "exit", and 
"eiror" which are used to stitch incoming and outgoing port parameters into/out of 
the congwsite step, and to handle runtime errors, respectively. 

In order to map, or "stitch" port parameters, a user should right-click on a 
link selection rectangle and select "map parameters. . from the appropriate link 
pull-right menu. The tool thereby aUows users to stitch outgoing port parameters, 
local step variables, and global application variables into and out of step instances. 

In this particular example, the workflow view 1006 shows a link 1008 
displayed in a warning color (such as red), indicating that the transition is mvalid. 
Popping up fee context menu on fcis link reveals feat fee "oportriport" arc is 
invalid 1010. Selecting fee "describe error" command from fee arc's context menu 
1012 displays fee errors described in fee messages pane 1014. To vaUdate fee 
entire project, fee user can click on fee "validate" button, or select 
"tools-validate project" from fee toolbar 1016. Again, this wiU generate a series of 
error, warning, and informational messages to be displayed in fee messages pane 
1014. Double-clicking on any message will cause fee tool to select fee relevant 
object and display fee.error location. 

Bdiavior filters can next be manipulated, as shown by fee screen 1 100 in 
Kgure 11. Bdiavior filters capture what information should be displayed in a 
region of a dynamically generated HTML page. For example, fee above filter 
1102 states feat fee usa- should be able to enter a text value for "operandi". 
However, feis filter does not state how fee text entry will be performed (e.g., using 
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a text field versus a text area HTML control). As a second example, "operator" 
1104 is defined as a "singleselect" behavior, meaning that the user has the abiHty 
to select one value out of a Kst of possible values. Again however, this does not 
specify how the user will choose the value (i.e., checkboxes, drop-down lists, etc.). 

Display filters are next shown being manipulated via screen 1200 in Figure 
12. In this example display filter, the user can arrange the elements that 
correspond to the behavior elements defined in the behavior filter into an 
arrangement of rows, columns, blocks, etc. For each display element, the user can 
select one of the vaUd ways to "implement" the associated behavior. For example, 
the "operandi" text entry behavior is hnplemented as a single-line text input field 
1202. The user can then select an alternative display style fi:om the list of valid 
display styles for the given behavior element via 1204. 

Screen 1300 in Figure 13 next shows how each display filter can also be 
viewed graphically. In other words, a graphical representation is shown that 
approximates the way the JSP (Java Script program) generated fi-om this display 
filter would be rendered in the HTML browser. As the user modifies the structure 
or display elements of the display filter in the structure view 1302, the form view 
(as shown) 1304 automatically updates to show the revised structure/content. 

Figure 13A further shows a constraction screen for use in laying out the 
actual appearance of the displayed elements or components. The palette 1350 
provides layout options of columns, rows, or blocks. A scrollable window 1352 
provides a list of objects that can be placed for display in the various layout 
options. The results vwndow 1354 allows for arrangement and display of the 
blocks, rows, and columns into a working display 1356. Through drag-and-drop 
operations (or the like). Operand 1 (1358) has been placed for display in the 
cotomn entry 1360. Other objects can similarly be placed through the working 
display. 

Figure 14 next shows an example page 1400 of the generated JSP showing 
the HTML ou^ut for the above display filter. Accordingly, the application 
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provides for the entry of a first operand 1402, a second operand 1404, and an 
operator 1406. By clicking on the "calculate" button 1408, a calculation result is 
produced. 

Figure 15 next shows a screen 1500 with the integrated tool and utilities 
1502 revealed in a pulldown menu. These tools and utilities include (but are not 
limited to): generate project makefiles - makefiles are used to by the buUd utility 
to capture the list of target objects and dependencies; build project - generates all 
files required by the project; clean project - ; generate folder makefiles - 
generates makefiles for selected folder and its children; build folder - generates 
files that depend on objects in selected folder; build folder recursive ~ generates 
files that depend on objects ia selected folder and its children; generate folder 
dependencies ~ generate dependencies for selected project; and clean folder ~ 
remove generated files based on objects m selected folder and its children. 

Figure 16 shows a screen 1600 resulting from the "validate project" selection 
1602 from the tool menu. By invoking this command, a list of messages is 
generated in the message pane 1604. Double-clicking on the message in pane 
1604 automatically selects ttie object and error location 1606. 

Figure 17 next shows a screen 1700 resulting from selectmg the "options" 
item from tiie tool pulldown menu. This screen allows the user to select the 
pathname for a Java source editor, which is used to edit Java source files. The 
screen also allows selection of an HTML viewer, which is used to edit HTML 
wireframe files. 

Figure 18 next shows a screen 1800 with an exan^le of defining object 
navigation via object choosers and invokers. Note that each microtemplate refers 
to a dynamically generated region of an HTML page. A display filter is used to 
describe the dynamically generated content. In this present exan^le, the content 
of Aemicrotemplate named "MTl" 1802 is generated by display filter 
"com-asera. . .dCaIcuIatar_Form". In order to select a valid value for a display 
filter, the user would dick on the "..." (choose) button 1806 to launch a smart 
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object chooser (see Figure 19) that will display a list of valid display filters. In 
order to view or edit the corresponding display filter, the user would use an 
invoker by cKcking on the "edit" button 1808. This will automatically select the 
display filter in the details pane. On the other hand, for wirefi-aroe candidates 
1810, the chooser would show the list of available HTML files, while the invoker 
would launch the preferred HTML browser/editor of the user to view/modify the 
HTML file. 

Figure 19 thereafter shows a screen 1900 which uiplements a smart object 
chooser that is used to select a valid display filter. 

Although the foregoing invention has been described in some detail for 
purposes of clarity of understanding, it will be apparent that certain changes and 
modifications may be practiced within the scope of the appended claims. 
Therefore, the described embodunents should be taken as illustrative and not 
restrictive, and the invention should not be limited to the details given herein but 
should be defined by the following claims and their full scope of equivalents. 
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CLAIMS 

What is claimed is: 

1 . An integrated design environment to facilitate formation of a 
business application having business objects, business steps, and other 
components which are mamtained as independent files, the resultmg busmess 
application to be used on a commerce server system, the integrated design 
environment conpising: 

an area for displaying a project tree hierarchy and selectively choosing a 
project file for graphical display; 

a detail viewing area for selectively displaying stractured and graphical 
views of Ihe project file; 

a properties configuration area for displaying and editing properties 
associated with a selected item in the detail viewing area; 

a comments area for displaying and faciUtating entry of comments 
associated with a selected item in the detail viewing area; and 

a message area for displaying a variety of warning, error, and/or status 
messages associated with vaHdation of the project file in relation to the various 
interdependendes of the object files con^sing the business application. 

2. The integrated design environment of Claim 1, wherein the detail 
viewing area displays various graphical views of particular project file when that 
projaa file is selected. 

3. The integrated design environment of Claim 2, wherein a context- 
sensitive toolbar is provided with selectable actions dependant upon the items 
being selected in Ae detail viewing area. 
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4. The integrated design environment of Claim 3, wherein each 
defined business object includes a tabular view that shows a list of attributes that 
con^rise the business object, and properties associated with each attribute. 

5. The integrated design environment of Claim 4, wherein each 
defined business object includes a tabular view that shows a list of relations with 
other business objects, if any such relations exist. 

6. Ihe integrated design environment of Claim 1, wherem each 
con^osite business step includes a graphical workflow view that provides a 
graphical workflow editor to edit the step instances and links in the composite 
step. 

7. The integrated design environment of Claim 6, wherein the 
workflow editor is used to move the step instances through drag-and-drop 
operations on labels associated with the step instances. 

8. Ihe integrated design environment of Claim 7, wherein the 
workflow editor is used to create and/or move links between source and target step 



9. The integrated design environment of Claim 8, wherein the source 
and target step instances have associated input and output ports, and the link 
instances are mapped to the input and output ports. 

10. The integrated design environment of Claim 9, wherein when a step 
or link is correctly mapped, then the associated label is color coded to indicate its 
correctness, and when the step or link is incorrectly mapped, then the associated 
label is color coded to indicate its incorrectness. 

11. Hie integrated design environment of Claim 10, wherein the 
incorrectly mapped step or link can be selected, and descriptive error messages 
will be shown in the message area. 
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12. The integrated design environment of Claim 1 , wherein a behavior 
filter is used for arrangement of behavior elements, the behavior filter being used 
to capture information that should be displayed in a region of a dynamically 
generated display page. 

13. The integrated design environment of Claim 12, wherein a display 
filter is used for arrangement of display elements that correspond to the behavior 
elements defined in the behavior filter, the display filter being used to arrange 
valid ways to inoplement the associated behavior. 

14. The integrated design environment of Claim 13, wherein valid ways 
to arrange display elen^nts include rows, columns, and tables. 

15. A formation and validation tool for building a business application 
having con^wnents which are mamtamed as independent files, the resulting 
business application to be used on a commerce server system, the tool comprising: 

a fib representation; 

a metadata layer for reading the file representation and creating a basic 
object representation of a particular conqjonent; 

an object model representation layer that uses the metadata layer to capture 
information necessary to perform cross-component project validation; 

an ^Ucation buUder device that uses the object model representation 
layer to form and display ^plications; and 

a commerce server device that uses the metadata layer to retrieve the 
information fi:om con^nents needed to execute the business application. 

16. The formation and validation tool of Claim 15, wherein the file 
representation includes a project ffle that encodes tiie names of constituent file 
conqjonents and oflier project settings. 
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17. The formation and validation tool of Claim 16, wherein the project 
file is written in a tjrpe of markup language. 

18. The formation and validation tool of Claim 15, wherein the object 
model representation layer is semantically richer than the metadata layer. 

19. The formation and validation tool of Claim 15, wherein the object 
model representation layer includes at least one project object, each containing a 
collection of references to document objects. 

20. The formation and validation tool of Claim 15, wherein each 
document object reference contains a reference to a corresponding document user 
interface object, and a reference to a document tree node object that is the root of 
the hierarchical representation of the document. 

21. Hie formation and validation tool of Claim 20, wherein each 
document is described as a hierarchy that is constructed from variants of the 
document tree node objects. 

22. The formation and validation tool of Claim 21, wherein each variant 
can be customized to serve in a variety of situations. 

23. The formation and validation tool of Claim 21, wherein the 
document tree node objects support a common set of functionality. 

24. An integrated design environment for the formation of applications 
to be run on a commerce server system, the integrated design environment 
conoprising: 

a plurality of objects represented as files for forming the applications, 
whereby each of the files can be interdependent upon otiier files within flie system; 

a gr^hical di^lay for arrangement of the plurality of objects; and 

a validation routine for verifying the interdependencies as being 
functionally correct for the given object arrangement 
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